Method and system for creating universal location referencing objects

ABSTRACT

A method and system for creating and/or using a universal location referencing object (ULRO) with electronic files including electronic maps. ULROs establish traversable links between a file-of-reference and third-party-files. In accordance with an embodiment, the ULRO comprises a universal location referencing code uniquely corresponding to the location, together with several optional components, including: a set of name information; a super-set of coordinates; a file-of-reference pointer field comprising a file-of-reference pointer; a third-party-file pointer field comprising one or more third-party-file pointers; a file-of-reference back-pointer field comprising a file-of-reference back-pointer; a third-party-file back-pointer field comprising one or more third-party-file back-pointers; and a metadata field. ULROs allow recognition of equivalence of features in different maps, and facilitate dynamic combination or linking of multiple maps into one virtual map, with traversable connectivity for a wide variety of map formats.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is related to provisional U.S. Patent Application No.60/797,130 entitled “SYSTEM AND METHOD FOR PROVIDING A VIRTUAL DATABASEENVIRONMENT AND GENERATING DIGITAL MAP INFORMATION,” Inventors: GilFuchs, Ettie Ettinger, Allen Brown, and Eric Crowe, filed May 2, 2006,now abandoned; and

Pending U.S. patent application Ser. No. 11/742,937 entitled “SYSTEM ANDMETHOD FOR PROVIDING A VIRTUAL DATABASE ENVIRONMENT AND GENERATINGDIGITAL MAP INFORMATION,” inventors Gil Fuchs, et al., filed May 1,2007, and incorporated herein by reference.

CLAIM OF PRIORITY

This application is a divisional of pending U.S. patent application Ser.No. 11/927,569 entitled “METHOD AND SYSTEM FOR CREATING UNIVERSALLOCATION REFERENCING OBJECTS” by Gil Fuchs, filed Oct. 29, 2007, whichis a continuation of U.S. patent application Ser. No. 11/271,436entitled “METHOD AND SYSTEM FOR CREATING UNIVERSAL LOCATION REFERENCINGOBJECTS”; both applications from which priority is claimed and bothapplications which are incorporated herein by reference.

COPYRIGHT NOTICE

-   -   A portion of the disclosure of this patent document contains        material that is subject to copyright protection. The copyright        owner has no objection to the facsimile reproduction by anyone        of the patent document or the patent disclosure, as it appears        in the U.S. Patent and Trademark Office patent file or records,        but otherwise reserves all copyright rights whatsoever.

FIELD OF THE INVENTION

The invention is related to electronic maps, electronic documents, andelectronic databases, and, specifically, to a method and system forcreating universal location referencing objects for use in suchelectronic maps, documents, and databases

BACKGROUND

Historically, documents were printed on paper or other non-modifiable,non-interactive media, and did not allow any user modification of theinformation, or, for example, of relationships between data points.Moreover, documents could not be updated when new information appeared,and the concept of “databases” in the modern sense of this word did noteven exist, rendering the concept of updating them moot.

Prior to the computer age, there were essentially two forms of recoursewhenever a map needed modification: 1) to enter a correction by hand onthe paper copy or copies of the map; or 2) to reprint the map with thecorrection made on the original. Manual corrections are time-intensive;particularly for multiple modifications, and by definition do not updateany of the other remaining copies of the map. The second option ofreprinting the map is expensive, and is also an impractical way torespond to frequent modifications.

In the current age, paper maps have been largely superceded bydatabases, documents, and maps in digital, electronic formats, capableof being updated as desired and able to respond to a selected range andtype of operator input and to produce operator-requested output. Manyelectronic documents and electronic databases in common usage todaycomprise information related to geographic location(s). Indeed, it isnot easy to think of a class of electronic documents or a class ofelectronic databases that does not at least occasionally incorporatesome form of geographically related information.

Examples of electronic databases that is relevant to certain embodimentsof the present invention are “geospatial databases”, commonly referredto as “electronic maps” or “digital maps”. Today, maps have evolved wellbeyond their centuries-old status as static paper depictions of anon-adjustable data set as recorded at one particular time. Forsimplicity, much of the discussion below refers to electronic maps,although the points made also apply to electronic documents andelectronic databases, other than maps, that contain geographicinformation.

One of the benefits of a digital map over a traditional paper-based mapis its inherent flexibility and its ability to portray large amounts ofdata. Paper maps are necessarily limited in the amount and type ofinformation they can portray, within the constraints of their physicalformats. Paper maps are also difficult to update.

Digital maps do not suffer from these problems. While earlier digitalmaps may have seemed merely like a scanned version of the paper product,today's modern digital maps are much more powerful. Information can beincluded in the map and either displayed, or not displayed, depending onthe wishes of the operator.

Today's digital maps, also known as electronic maps, can allow forregular modification of data points included in the map, in addition toactive operator selection of desired geographic features of interest. Asnew information arises, of a type specifically relevant to a map ofinterest, the whole map can be quickly updated to reflect changes orcorrections to all or just a small subset of locations.

Digital maps may be capable of responding to certain types of operatorinput and may be capable of offering a range of operator-adjustableoutput. Current electronic maps may offer the operator the option toselect the scale at which the map is viewed. Often this is done using a“zoom-in” and/or “zoom-out” capability. This feature, while importantand useful, does not actually change the content contained in aparticular map, but rather re-presents the map at a different level ofdetail and with a different geographic focus.

A typical application of electronic maps is in the travel industry,whereby digital maps are used to quickly and automatically chart travelroutes and to locate destinations. Digital maps have found aparticularly common everyday use in automobiles, wherein GlobalPositioning Systems (GPS) and other position determination devices areused in association with a digital map to automatically track theposition of a car and display the position on a map, for example, toguide the driver to a particular destination.

Digital maps are often also used in commercial environments, forexample, in calculating optimized routes for delivery drivers to takewhen performing deliveries, or for providing accurate directions foremergency and medical crews to follow when responding to emergencycalls. For many years, the electronic map industry has also suppliedmaps to the military for use in military applications. Digital maps finda use in all aspects of industry, including for ground-based, maritime,and aviation purposes. As people have become more familiar withportable, handheld electronic devices such as Personal DigitalAssistants (PDA's) and smart phones, which are increasingly distributedtogether with electronic maps stored therein, the electronic or digitalmap industry has grown to infiltrate virtually every aspect of society.

Some currently available digital maps allow for linking between a textaddress and its location on the map. If, for example, an operator inputsa street address into the Yahoo! Maps software application, MapQuest, ora similar Internet mapping website, the output indicates the location ofthat particular address on a map that is drawn of the surrounding area.Essentially a map of the region encompassing the address of interest isconstructed around the selected point. The map may contain overlays ofuseful information. For example, a street map of San Francisco may beoverlaid with a map of the railroad system in San Francisco and that mapin turn overlaid by icons representing San Francisco restaurants andparking facilities.

However, these various overlays are “map-level overlays”, meaning thatthey are registered one to another on the basis of their coordinates. Nointeractivity is typically available between different points in theoverlay or between a point in one overlay and a point in anotheroverlay. While such a coordinate overlay may result in something thatappears to an end-user like a single map, it cannot dynamically functionlike one fully integrated, intelligent digital map. In a sense, theentities in one layer know nothing about the entities in any other layerand hence cannot support further data processing related to usefullinkages between those entities. Moreover, such an overlay map is onlypossible if it is permitted by the scales, formats and coordinatesystems of the different maps and different spatial data files. Such anoverlay map is not feasible if the information in one or more documentsis not presented in the form of a map.

For example, the restaurant information may take the form of a text listof restaurant names and addresses. In this case, using traditionalmethods there is no easy way to seamlessly integrate the restaurant datawith the railroad and street data of our example. Solutions in the pastsimply found the coordinates of the restaurant by finding its addresslocated within the street map and generating a set of icons to displayas an overlay. While this allowed for a simple address linkage it wasincapable of any more sophisticated linkages.

Alternatively, a richer set of linkages could be made possible, but onlyif all information has been comprised within the same single integratedmap file. This puts the increasingly untenable burden on a single mapvendor to integrate the entire body of spatial knowledge into a singleelectronic map. However, in most situations, the map vendor doesn't evenhave access to all the necessary information, so despite their bestintentions, it is increasingly difficult to create a completelyintegrated map.

Finally, in accordance with traditional methods, any changes in theplacement of an entity on one layer cannot automatically be coordinatedwith entities in other layers, thereby requiring much extra work inkeeping all of the layers integrated.

With the progression of the Internet and generally, the information age,increasingly more data with spatial components is becoming available,that could be linked together in an integrated intelligent electronicmap. It is a shortcoming of the traditional methods that the layeredapproach will not handle such intelligent linkages, and hence will limitthe ability to query the full richness of the spatial content becomingavailable. Also, because of the intensive labor in keeping thecoordinate-related data synchronized, the traditional techniques limitthe overall amount of data that can be maintained and updated. Moreover,given the explosion of spatially related information that is digitallyavailable and of interest to map users it is neither economically norlogistically feasible for map-related enterprises to create and maintainthe entire universe of such information. It is these, and otherlimitations of the prior art that the present invention is designed toaddress.

SUMMARY

Generally described, the invention presents a method and system forcreating universal location referencing objects (ULROs) for use inconjunction with electronic documents, electronic databases, andelectronic maps, which are collectively referred to herein as“electronic spatial data files”. Virtually everything stated hereinregarding one type of electronic spatial data file can also be appliedto another type of electronic spatial data file with no loss ofapplicability. A single logical spatial data file may be partitioned.One logical electronic spatial data file may thus comprise one or morephysical files, which may or may not have geographic definitions.

To address the limitations described above with respect to traditionalmethods, it is desirable to devise a system for creating “virtual maps”.A virtual map is defined herein as a digital map capable of dynamicallyconnecting information contained in one or more databases, andpresenting it to an operator seamlessly and in real time. Typically,modern electronic maps are not able to link points of interest in oneelectronic map or database with points of interest in a secondelectronic map or another database to create a virtual map withrelationships between the objects in one map and the objects in thesecond map or database.

It is an objective of the present invention to create a ULRO object thatcaptures the salient information of a location; comprising geographiclocation, a name associated with that location and a permanentidentifier for that location.

It is a further objective of the present invention to create ULROs toenable linking the items of a database that can be spatially defined, ordata related to such items, to a map database and thereby enabling aVirtual Database (VDB) to offer a user access to a seamless electronicdatabase with a greater richness of dynamically linked content.

It is a further objective of the present invention to create ULROs toenable the linking of items of a database that can be spatially defined,or data related to such items, to a map database and thereby enabling auser to select all desired content to be compiled and packaged or storedon media, such as a CD or DVD, for use in off-line products such as aembedded navigation system.

It is a further objective of the present invention to build a ULROstructure that facilitates the initial registration or linking of a vastamount of distributed data, even those with different formats, and, oncelinked with both forward and reverse pointers, facilitating the fast andefficient generation of intelligent maps, customized with theappropriate information to meet the user's request.

It is a further objective of the present invention to minimize thestorage space needed to store the many relationships, groupinggeographic items of the same location, reducing such space requirementsfrom typically a size proportional to N! (N factorial, where N is thenumber of distributed links containing pertinent information), to afactor proportional to N, and to similarly improve upon the speed ofsearching, reducing it from something proportional to N² (N-squared) tosomething proportional to a constant value, C.

It is a further objective of the present invention to enable independentmaintenance of the map and of the third party databases, therebyreducing the effort needed in keeping current the content of these largedatabases.

It is a further objective of the present invention to increases thespeed and efficiency by which information can be retrieved fromotherwise independent or third-party sources, and compiled in a dynamicfashion so that it can be easily updated and searched, as newinformation becomes available.

It is a further objective of the present invention to enable ahierarchical construction of ULROs, and to provide a means by which theycan relate to one another in a uniform way.

As described herein, an embodiment of a ULRO comprises a permanentidentification code designed to identify a selected location. A locationin turn may be associated with one or more geographic items. ULROs canbe employed to establish traversable links or connections between afile-of-reference and third-party-files for a broad range of databaseformats. A file-of-reference is a geospatial file used for permanentstorage of a file owner's geographic data. A third-party-file is ageospatial file used for permanent storage of a third party's geographicdata. Whatever its format may happen to be, a file-of-reference or athird-party-file can typically be transformed into other formats thatmay be more appropriate for certain applications. In accordance withvarious embodiments of the present invention, this technique can be usedto establish traversable links between a map-of-reference and one ormore of third-party maps and third-party-spatial data files.

As further described herein, in accordance with an embodiment a ULROpoints to geographic items associated with a common location and locatedin two or more different files. Often but not always, one of the filesis the database-of-reference. Effectively, a traversable link is therebycreated between the two files. ULROs substantially reduce the number ofconnections required to create traversable links between each of a set Nof documents. Using a traditional approach, each document would berequired to point to each other document, and each document would thenin turn be pointed-at by each other document, for a total number ofpointers on the order of N! (N factorial). The present invention makespossible a star configuration, which reduces the total number ofpointers required, to a number in the order of 2 times N. For a largenumber of documents, i.e. for a large value of N, this lowers the numberof connections by several orders of magnitude. Furthermore, since (a)the total number of connections is much smaller; and (b) the ULROtechnique eliminates the need to perform multi-discovery over many filesin favor of a direct, pointered access to those files; the resultantability to retrieve related map data is much faster using a ULRO thanwith traditional approaches.

As further described herein, in accordance with an embodiment a ULROcorresponds to a selected geographic item associated with a location. Inaccordance with one embodiment, a ULRO comprises eight principalcomponents, some or all of which may be utilized depending on theparticular implementation: 1) a set of name information; 2) a super-setof coordinates; 3) a universal location referencing code (ULRC) uniquelycorresponding to the location; 4) a file-of-reference pointer fieldcomprising a file-of-reference pointer; 5) a third-party-file pointerfield comprising one or more third-party-file pointers; 6) afile-of-reference back-pointer field comprising a file-of-referenceback-pointer; 7) a third-party-file back-pointer field comprising one ormore third-party-file back-pointers; and 8) a metadata field.

In accordance with an embodiment, the file-of-reference pointer fieldand the third-party-file pointer field are each contained within theULRO. Both of the back-pointer fields are contained within theirrespective files. The file-of-reference, third-party-file and ULROs canbe located remotely from each other. The eighth component is a metadatafield comprising metadata related to the ULRO. In accordance with anembodiment, the only mandatory field in the ULRO is the ULRC. It is alsomandatory that the set of name information and the set of coordinatesnot both be blank, although either one or the other can be blank for aparticular ULRO.

Using the above example of map containing restaurant information, andtext entries, using the ULRO approach additional attributes can beintegrated and presented to a user regardless of whether the informationis contained in the form of a map or in another form. For example, ifthe restaurant information is a text listing of restaurant names, it canbe combined with the railroad and street maps to create a virtual map aseasily and effectively as if the restaurant information was in mapformat. Through the use of ULROs, it is easier for operators of end-userapplications to obtain spatially relevant data from virtual maps.Virtual maps are capable of using the present invention to usefully andaccessibly combine the information in a file-of-reference withinformation comprised in one or more of a variety of third partysources. For example, the ULRO techniques may also be used together witha virtual map database technique, described in further detail inco-pending application Ser. No. 11/742,937 entitled “SYSTEM AND METHODFOR PROVIDING A VIRTUAL DATABASE ENVIRONMENT AND GENERATING DIGITAL MAPINFORMATION,” inventors Gil Fuchs, et al., filed May 1, 2007, andincorporated herein by reference, to create virtual maps in a dynamic,run-time fashion. In such a system, the user can, for example, obtainanswers to such questions as: “Show me Italian restaurants near theGeary Theater, and for each restaurant, show me the parking garages thatwill validate parking”.

These and other objectives, advantages, and benefits of the presentinvention will be evident from the accompanying detailed description anddrawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an illustration that depicts the assignment of ULROscomprising permanent ID codes, to locations in an electronicfile-of-reference, in accordance with an embodiment of the invention.

FIG. 2 is an illustration that depicts a ULRO corresponding to aselected geographic item associated with a location in afile-of-reference, in accordance with an embodiment of the invention.

FIG. 3 is a flow chart that illustrates the typical flow of a process inaccordance with an embodiment of the invention that receives informationabout a geographic item associated with a location, and creates a ULRO.

FIG. 4 is a flow chart that illustrates in more detail the typical flowof a process in accordance with an embodiment of the invention thatreceives information about a geographic item associated with a location,and creates a ULRO.

FIG. 5 is an illustration that depicts the use of ULRO relationships andhierarchies, in accordance with an embodiment of the invention.

FIG. 6 is an illustration that depicts the use of ULRO groups, inaccordance with an embodiment of the invention.

FIG. 7 is a diagram that schematically illustrates an example of asystem that can be used with an embodiment of the invention.

DETAILED DESCRIPTION

Generally described, the invention presents a method and system forcreating universal location referencing objects (ULROs) for use inconjunction with electronic documents, electronic databases, andelectronic maps, which are collectively referred to herein as“electronic spatial data files”. Virtually everything stated hereinregarding one type of electronic spatial data file can also be appliedto another type of electronic spatial data file with no loss ofapplicability. A single logical spatial data file may be partitioned.One logical electronic spatial data file may thus comprise one or morephysical files, which may or may not have geographic definitions.

The following terms are used throughout this document:

Feature—A geographic feature (referred to herein simply as a “feature”)is an idealized map representation of an actual object from the realworld, which is useful to that map representation. Features have adimension, and most often but not always have geometric representations.Features might not be actually visible in the real world: such asborders or intersections, yet they can be represented in a map model.Features have a type and a class, which together allow the system todistinguish one feature from another, while also preserving similaritiesbetween features that are alike.

Dimension of Feature—Features are often represented in the map model ina more simple way than in their full “real world” complexity. Often thereal world complexity is more of a distraction than an asset to a model,which is just trying to capture a few salient aspects of the real worldin order to perform some particular function. Thus, the dimension of afeature does not reflect the real world truth, but rather what therepresentation has rendered.

The five dimensions that features are divided into include: pointfeatures, line features, area feature, volume features, and complexfeatures. Real world features which are represented as points are knownas point features. For example, a restaurant (even though it is, in thereal world, a volume object with complex shape), when represented in themap model is conveniently represented as a point feature. So is, forexample, a junction where two or more roads elements cross each other.Line features are represented as linear or simple curved segments (andas such have an extent which runs between point features or intermediateshape points). Roads, borders, rivers are some examples of linefeatures. Of course, these real world objects are not razor-edge thin,but in the map model they are represented as idealized center lines,ignoring their actual width. Lakes, parks, and administrative areas areexamples of area features. Volume features, such as buildings, (absentfrom most map models) are represented as a construction of connectedarea features in a way that resembles the real world, although quiteoften with much less detail. Lastly, complex features are features whichare not “atomically” defined (this term is described in further detailbelow).

Type of Feature and Class of Feature—Types and classes are subcategoriesof features that enable them to be distinguished. Roads, rivers, traintracks, cities, counties, mountain peaks, bus stops, intersections,bridges, restaurants, hotels, rest areas are but a few examples of typesof features. In most commercial map models there may be thousands ofdifferent feature types. The ISO-GDF (Geographic Data File) map formatis one standard format, which, among other things, attempts to list acorpus of well-known feature types. Complete details of the GDF formatare described in the ISO specification “ISO 14825: Intelligent TransportSystems—Geographic Data Files (GDF) Overall Data Specification”,incorporated herein by reference.

Within a particular type of a feature there may also be a variation. Forexample, there are different classes of roads in the world: highways,major roads, minor roads, rural roads, residential roads, slip roads,dirt roads, and goat trails. While these are all of the feature type“road”, they differ in their various classifications—hence a featureclass is subordinate to the feature type.

Geometry of Feature—In the computer map model, features often have ageometrical representation of the feature's shape. Point features arerepresentation by a single node. Line features are often represented bylinear segments—edges—which may run through a sequence of shape points.Area features may be represented by a collection of faces, each of whichconsists of edges delineating its boundary. Area features may bedisconnected or may even have holes in them. Volume features may berepresented by volume geometry, which might contain cavities.

Topology—Topology is a set of mathematical properties that are used as ameans of capturing connectivity relationships between features whichremain true even when the geometry (shape) of the feature might undergosome change. Geometries of some dimension are bounded by geometries oflesser dimension. Volumes are bounded by areas. Areas are bounded bylinear segments, linear geometries are bounded by points. Inversely,points are co-bounded by linear geometries. Linear boundaries areco-bounded by areas. Finally, areas are co-bounded by volumes. Topologymay be an aspect of the features themselves, or of the geometry whichcaptures their shape.

Simple Feature—Point features, line feature, area features, and volumefeatures are simple features, since they are directly modeled byassigning geometrical shapes to them.

Complex Feature—Conversely, complex features may be indirectly definedby other features (simple or complex), as well as by direct geometricalrendering. For example, the state of California may be represented notby running its boundary with shape points (which would make it a simplearea feature), but rather as the sum of its counties (which themselvesmay be simple or complex features). California State, rendered as acomplex feature, is a single feature, which is defined in a complex wayby referring to other features. Roads which consist of two roadelements—one in each direction of traffic—are another common example ofa complex feature. When two complex roads meet, a complex feature isdeclared, namely, the complex intersection. Often an intersection can bethought of as four junctions, where the simple road elements cross eachother.

Plurality of Features—Both the simple and complex features describedabove are examples of single features. It is, however, sometimes usefulto think about several features at once, hence creating a plurality offeatures. For example, the collection of all of the restaurants in SanFrancisco, or all of the counties in California serve as examples of aplurality of features. Note that the plurality of features (for example,all the counties in California) is a different concept from the singlecomplex feature of the State of California (although in this examplethey do have the same geometric footprint).

Sub-Set of Feature—It is sometimes convenient to identify a portion,sub-set, or a part of a single feature. Sometimes such parts may befeatures in their own right, but at other times, such parts are merefragments, which on their own would not be actual features. Examples ofa sub-set of a feature include a single county of the State ofCalifornia feature, a segment of road element spanning just a fractionof a block between two intersections, or floors 4 through 17 of a30-story building.

Attribute—Features, plurality of features, and sub-sets of features mayhave attributes. Attributes are provided in large catalogs, and theremay be thousands of different attributes applying to features in acommercial computer map model of the real world. The attribute type iswhat captures the different attributes from the catalogue. Speed limit,length, direction of traffic flow and restaurant opening hours are but afew examples of such attributes.

Relationship—Relationships are comprised of two or more features“participating” in some meaningful connection to each other. Forexample, a road element might split into several road elements at somejunction, and hence all of those features are in a “fork” relationshipto each other (each feature playing a different role). Relationships arealso provided in large catalogs, and, as with attributes, hundreds ofsuch relationships are possible in actual commercial digital map models.Not all relationships are geometric, since many are developed bymodeling real-world activities. For example, the restaurant thatvalidates parking for a particular parking garage represents one type ofbusiness relationship between two features.

Geographic item—For the purpose of this description, a non-ISO standardterm is employed here. A geographic item is defined here to be either afeature, a plurality of features, a sub-set of a feature, or anattribute.

Location—The location where a feature is in the real world is distinctfrom the feature itself. For example, while the feature may be therestaurant, its location can be specified as some latitude, longitude(lat/long) coordinate pair, or coordinates from some similar geodeticreferencing system, or as a human readable address, (for example “322Battery Street” in San Francisco). Locations should not be confused withfeatures or with the other geographic items associated with thelocations.

Hierarchy of features—Features often form a hierarchy of construction.For example, a country may be comprised, or made up, of States orProvinces, while States may be comprised of counties etc. In a similarmanner, roadways are made up of many block face road elements. The roadsand parks and buildings of the complex area which comprise “the StanfordUniversity campus area” are parts of the larger feature. The hierarchyof features is a special case of a relationship between features, and itcan be explicitly captured and represented, or not.

Point of interest—A point of interest (POI) is a special type of pointfeature, in particular it is a type that may comprise other morespecific types, such as a restaurant, hotel, museum etc.

As described herein, in accordance with an embodiment, a ULRO comprisesa permanent identification code and sufficient information designed touniquely identify a selected location. A location, in turn, may beassociated with one or more geographic items. ULROs can be employed toestablish traversable links between a file-of-reference and one or aplurality of third-party-files for a broad range of database formats.ULROs can be similarly employed to establish traversable links betweentwo or more third-party files.

As also described herein, in accordance with an embodiment, afile-of-reference is a geospatial database used for permanent storage ofa document owner's geographic data. A file-of-reference can typically betransformed into other formats that may be more appropriate for certainapplications. In accordance with an embodiment there is only onefile-of-reference database identified to support ULROs. A third-partyfile is any file that contains some element of spatial data, which mayconsist of geographic features, attributes of features or relationshipsof two or more features. A third party file is distinct from thefile-of-reference.

ULROs uniquely correspond to a particular location. A document need notbe a map in order to comprise a geographic item that is associated witha location. ULROs can be easily updated as information changes and asmore precise information is obtained. ULROs point to geographic items intwo or more different files that are associated with the same location,so that a traversable link or connection is effectively created betweenthe two files. ULROs are not required in order to create traversablelinks between different documents comprising geographic information.ULROs do, however, substantially reduce the number of connectionsrequired to create traversable links between each of a set, N, ofgeographic items. Generally the N geographic items can be found in Mseparate files, where M is a value less than or equal to N. Using atraditional approach, each document would be required to point to eachother document, and each document would then in turn be pointed-at byeach other document, for a total number of pointers on the order of N!(N factorial). The present invention makes possible a starconfiguration, which reduces the total number of pointers required, to anumber in the order of 2 times N. For a large number of documents, i.e.for a large value of N, this lowers the number of connections by severalorders of magnitude. Furthermore, since (a) the total number ofconnections is much smaller; and (b) the ULRO technique eliminates theneed to perform multi-discovery over many files in favor of a direct,pointered access to those files; the resultant ability to retrieverelated map data is much faster using a ULRO than with traditionalapproaches.

EXAMPLE IMPLEMENTATION AND USAGE

In accordance with an embodiment and an example implementation, a ULROcorresponds to a location associated with a geographic item in anelectronic file comprising spatial data. The ULRO comprises eightprincipal components:

1) a set of name information (for example, the address “32 El CaminoReal”);

2) a super-set of coordinates comprising k sets of coordinates, where kis the number of geographic points in the location (for example, a pointlocation for the address “4 Embarcadero Center, San Francisco” is anexample of a set of coordinates that could be comprised in thesuper-set: −122.39730 degrees longitude, 37.79519 degrees latitude,elevation of 3 meters above sea level);

3) a universal location referencing code (ULRC) uniquely correspondingto the location (for example, 63573);

4) a file-of-reference pointer field comprising a file-of-referencepointer, either contained in a “side file” located externally to theULRO, or located internally to the ULRO;

5) for each geographic item associated with this location, a pointerfield comprising a third-party file pointer;

6) a file-of-reference back-pointer field comprising a file-of-referenceback-pointer;

7) a third-party file back-pointer field comprising one or morethird-party file back-pointers; and

8) a metadata field. A metadata field comprises metadata relating to theULRO.

Of the above-described fields in the ULRO, the only mandatory field isthe ULRC. In accordance with an embodiment, it is also mandatory thatthe set of name information and the set of coordinates not both beblank, although either one or the other can be blank for a particularULRO. The actual requirements for each field may vary depending on theactual implementation.

In accordance with an embodiment, the first two of these components,i.e. the set of name information, and the super-set of coordinates (suchas longitude, latitude, elevation or a linear referencing system such asthose used in conjunction with major motorways or cell phone towers),may be thought of as coordinates in two different reference spaces. Thegeographical coordinate reference space is mathematically based,precise, and exhaustive in the sense that it uniquely and unmistakablynames every point on earth. The name reference space, by contrast, islinguistically and historically based, imprecise, and incomplete. Namesare often duplicated multiple times between different objects in waysthat can be trivial or can be confusing. For example, Paris is thecapital of France, in addition to being a city in Texas, and a town inMaine. Even a name such as “the Eiffel Tower” can refer both to one ofFrance's most beloved landmarks as well as to its imitation in front ofa popular hotel in Las Vegas. By contrast, no confusion occurs when oneis provided with coordinates such as −122.39730 degrees longitude,37.79519 degrees latitude, and 3 meters above sea level.

In accordance with an embodiment, the set of name information furthercomprises one or more of the following: 1) an address, such as 1a) apostal code, 1b) a street number, 1c) a street name; 1d) a hierarchicalarea address system with a sequence of names; and 1e) other addressinformation; 2) a named place; 3) geographic name information; 4) othertypes of name information such as telephone numbers and 5) any othername meta-information. Geographic name information in turn comprises oneor more of the following: 5a) name information for a point feature; 5b)name information for a line feature; 5c) name information for an areafeature; 5d) name information for a volume feature; 5e) name informationfor a segment of a line feature; 5f) name information for a sector of anarea feature; 5g) name information for a section of a volume feature;and 5h) name information for a plurality of related geographic items.

In accordance with an embodiment, the hierarchical area address systemincludes information on the relationship among at least two of the typesof geographic information. For example, name information in the case ofthe University of California, which is an area feature, could includethe fact that the University is located in Berkeley, which is in turnlocated in Alameda County, which is in turn in California, which is inturn in the United States. By comparison, “El Camino Real” is a name foran entire street, which forms a line feature. A line feature isdescribed by a series of points. The address “32 El Camino Real” is apoint address at a specific location along the line feature. Clearly,the address “32 El Camino Real” can occur in various different cities(and or counties). Each of those occurrences is a point address locatedat a specific location along the line feature or at a point feature. Touniquely designate it, it is often necessary to add an appropriate city,county and state context.

In accordance with an embodiment, the super-set of coordinates comprisesa number k of coordinate sets, wherein k is the number of geographicpoints comprised in the location. Each coordinate super-set comprisesone or more of a geographic coordinate set. Each coordinate super-setmay in addition comprise one or more of a coordinate classification suchas a defined coordinate reference system. One such geographic coordinateset comprises the coordinate reference system of a latitude and alongitude, and may in addition comprise an elevation. Other coordinatesets may include other geographic coordinate reference systems such asUniversal Transverse Mercator (UTM), or a linear referencing system suchas those used in conjunction with major motorways or cell phone towers.

In accordance with an embodiment, a third component of a ULRO is a ULRC.A ULRC is assigned so as to uniquely correspond to the location. Once aULRC is retired, it cannot be reused. In one embodiment, the ULROcomprises a counter capable of ensuring that the assigned ULRC was notpreviously assigned to another location. According to anotherembodiment, once created, a ULRO may be stored in a central repositoryof ULROs, each of which is indexed according to its ULRC. This providesan alternative way to the counter of ensuring that ULRC's are notreused. When an already created ULRC is needed, the repositoryrecognizes this and provides the appropriate ULRC, so that a new one isnot created, which would be duplicative, needless, and confusing.

It may not be immediately apparent to the reader why both the set ofname information, and the super-set of coordinates (components 1 and 2respectively) of the ULRO are necessary when the ULRC is alsoincorporated as part of the ULRO. However, such apparent redundancy isdesirable to ensure smooth, error-free integration of information fromdifferent sources. By way of example, a determination may be needed asto whether new item 3823 from data source B can be associated with anexisting ULRO, or alternatively needs a new ULRO created. Nameinformation and coordinate information serve as a means of discoveringthe correct ULRO, if it exists. Once so discovered, the geographic itemthen points to that ULRC, and future retrievals no longer require nameand coordinate comparisons. If no such ULRO is found, then a new ULRO iscreated and the geographic item is associated with that. Otherwise, itmight, for example, be possible to confuse the Canadian province ofOntario with the town of Ontario in Southern California, or to confuse“32 El Camino Real, Menlo Park” with “32 El Camino Real, Palo Alto”.

It is common for a location to have the same name as the street on whichit is located, and it is extremely common for streets of the same nameto comprise multiple sections located at a number of different places ina particular city. Some American states even have more than onemunicipality of the same name, making confusion likely in the absence ofsuch additional information as name information and coordinateinformation. Thus, all three are necessary to adequately describe aparticular location—the first two being needed to describe the locationand the third needed to effectively facilitate traversibility andcompactness.

As a practical matter, most files will contain some form of databelonging to at least two of these three categories of information.Under most circumstances, the two categories will suffice to form thecorrect item-to-item link, but certainly with all three categoriespresent, such a linkage can be formed without problem. Once a ULRO iscreated all associated geographic items can be linked in third partydata. It is at this time that all the fields of the ULRO can be used tomake an accurate decision as to which geographic items should go withwhich ULROs (i.e. which objects are different manifestations of the samelocation).

For example, in the case of “El Camino Real”, an object in thefile-of-reference representing that street might be preliminarilyequated with an apparently corresponding object in a map created by athird party. The two maps might disagree about some details relating tothe street, but once the equivalence of the two objects is established,then name information and coordinates become less critical to thelinkage of the two objects and the two maps.

Furthermore, the ULRC uniquely corresponds to the location and is notduplicated with any other location. Once assigned, a ULRC can only beused with reference to the location to which it is assigned. The ULRCwill normally remain the same for the same location. The fact that aparticular location is always described by the same ULRC facilitatesreconciliation of different maps that may have been created pursuant todifferent mapping algorithms and/or pursuant to different mappingtechnologies. The ULRC enables the matching and/or joining of differentelectronic files, such as electronic maps or an electronic map with aseries of third party spatial data content files.

In accordance with an embodiment, a fourth component of the ULRO is thefile-of-reference pointer field. The file-of-reference pointer fieldcomprises a file-of-reference pointer, which uniquely designates ageographic item associated with a location in the file-of-reference.Each file-of-reference pointer may further comprise one or more of thefollowing: a time of creation of the file-of-reference point, a type andclass of the file-of-reference pointer, and other file-of-referenceinformation.

In accordance with an embodiment, a fifth component of the ULRO is thethird-party file pointer field. The third-party file pointer fieldcomprises one or more third-party file pointers, each of which uniquelydesignates one or more geographic item that refer to said location inone of said one or more third-party files. The number, n, ofthird-party-pointers pertaining to a particular location equals thenumber of separate geographic items summed over the number ofthird-party files comprising the location. There can be many third-partydatabases, but only one file-of-reference.

The third-party file pointer field may further comprise one or more ofthe following: a time of creation of the third-party file pointer, atype and class of the third-party file pointer, and other third-partyfile pointer information. The third-party file pointer field may eitherbe comprised in the ULRO or may be comprised in a side file external tothe ULRO.

In accordance with an embodiment, a sixth component of the ULRO is thefile-of-reference back-pointer field. The file-of-reference back-pointerfield comprises a file-of-reference back-pointer pointing from saidfile-of-reference back to the ULRC. Each file-of-reference back-pointermay further comprise one or more of the following: a time of creation ofthe file-of-reference back-pointer; a type and class of thefile-of-reference back-pointer; and other file-of-reference back-pointerinformation.

In accordance with an embodiment, a seventh component of the ULRO is thethird-party file back-pointer field. The third-party file back-pointerfield comprises one or more third-party file back-pointers, wherein eachsaid third-party file back-pointer uniquely points from one of saidthird-party files back to said ULRO, namely the ULRC. The number, n, ofthird-party-pointers pertaining to a particular location equals thenumber of separate geographic items summed over the number ofthird-party files comprising the location. Each third-party fileback-pointer may comprise one or more of the following: a time ofcreation of the third-party file back-pointer, a type and class of thethird-party file back-pointer, and other third-party file back-pointerinformation.

In accordance with an embodiment, an eighth component of the ULRO is themetadata field. The metadata field comprises one or more of thefollowing: a ULRO classification, a time of creation of the ULRO, a typeand class of the ULRO, and other metadata information.

The file-of-reference pointer field and the third-party file pointerfield may each either be contained within the ULRO or may be containedin a side file external to the ULRO. For any embodiment in which theULRO does not internally contain a file-of-reference pointer field, aside file containing the file-of-reference pointer field is defined.Similarly, for any embodiment in which the ULRO does not internallycontain a third-party file pointer field, a side file containing thethird-party file pointer field is defined. Those embodiments in whichthe ULRO internally contains both a file-of-reference pointer field anda third-party file pointer field will typically not require use of sidefiles. On the other hand, if the ULRO does not internally contain both afile-of-reference pointer field and a third-party file pointer field,side files containing the needed pointer field(s) will be necessary.When a new third-party is added a small modification to the URLO isneeded (but only if the third party pointer isn't stored in a sidefile), namely, a third-party pointer field is added to the ULRO (when ina side file, that is done in the side file and no modification to theULRO proper is required).

Application of ULROs to Virtual Databases and Virtual Maps

As described above, ULROs are designed to be used with reference tolocations. A ULRO is comprised of a ULRC, which comprises a permanentidentification code specifically designed to refer to a geographic itemthat is associated with a location. The ULRO encodes information aboutits corresponding location, thereby facilitating the grouping of relatedgeographic items associated with that location that are spread overpossibly many files As such, ULROs (and more particularly ULRC's) allowfor the recognition of the equivalence or identity of features in one ormore different maps. ULROs facilitate the dynamic combination of one ormore maps into one virtual map with traversable connectivity betweendifferent geographic items regardless of the map(s) that are theultimate origins of each geographic item. For example, if one considersa San Francisco map, embodiments of the present invention enable thecreation of a virtual map with traversable connectivity between elementsderived from a San Francisco street map, a San Francisco railroad map,and a San Francisco restaurant and parking facilities data file. Theinteraction of streets, restaurants, parking facilities and railroadswith each other can then be captured and offered to the operator. Withthe aid of the virtual database technology, described in co-pendingapplication Ser. No. 11/742,937 entitled “SYSTEM AND METHOD FORPROVIDING A VIRTUAL DATABASE ENVIRONMENT AND GENERATING DIGITAL MAPINFORMATION,” inventors Gil Fuchs, et al., filed May 1, 2007 andincorporated herein by reference, relationships between streets,restaurants, parking facilities and railroads can be specified by theoperator, and displayed as an output from the virtual map. For example,the operator may wish to know the street on which a particularrestaurant is located, and what parking facilities will take a parkingvalidation from that restaurant or what the train schedule is for trainsarriving at the nearby railroad station. This is more powerful than thetraditional layered view. Using traditional techniques, coordinates of alocation (which might be sufficiently accurate or not), together withthe process of reverse geo-coding, could be used to discover which otherstreets are “near”, but that process is both time-consuming andinaccurate. Also, with traditional techniques no mechanisms exist toenable relationships between disparate geographic items to bemaintained, short of integrating all data into a single electronic mapfile. In accordance with an embodiment of the present invention, directpointing and explicit relationships allow for both quick andindisputably accurate results.

Furthermore, additional attributes can also be folded-in regardless ofwhether the information is contained in the form of a map or in anotherform. For example, if the restaurant information is a text listing ofrestaurant names, it can be combined with the railroad and street mapsto create a virtual map as easily and effectively as if the restaurantinformation was in map format. Of course, the name of a restaurant mustbe augmented with spatial data, address or coordinates, so it can belinked to the appropriate ULRO. Further information that may beintegrated from data in map format, text format, or another format couldinclude, for example, the age of each house on a particular street or ina particular area, a list of owners of restaurants, a list of types offood served by each restaurant, train schedules, data on the age of eachtrain track, or the position of entrances to the area's rapid transitsystem. Once created, a virtual map is operationally indistinguishablefrom a single map with traversable links between items. Through the useof ULROs, it is easier for operators of end-user applications to obtainspatially relevant data from virtual maps. Virtual maps are capable ofusing embodiments of the invention to usefully and accessibly combinethe information in a file-of-reference with information comprised in oneor more of a variety of third-party sources.

ULRO Example Implementation

As described above, in accordance with an embodiment, some fields in theULRO can be left blank, while the only mandatory field is the ULRC. Itis also mandatory that the set of name information and the set ofcoordinates cannot both be blank at the same time, although either oneor the other can be blank for a particular ULRO.

FIG. 1 is an illustration that depicts the assignment of ULROscomprising permanent ID codes, to geographic items associated withlocations in an electronic file-of-reference, in accordance with anembodiment of the invention. As shown in FIG. 1, ULROs are assigned togeographic items associated with a location 120, 122, 124, 126 in anelectronic file-of-reference 130. In keeping with the definitionprovided above, the geographic items can be any of a feature, aplurality of features, a sub-set of features, or an attribute associatedwith a physical location, so that in FIG. 1 the geographic items 120,122, 124, 126 may in actuality be associated with a single physicallocation. ULROs 110, 112, 114, 116 comprise respectively ULRC's 134,136, 138, 140. In accordance with an embodiment each ULRC may in turncomprise a permanent identifier or permanent ID. The ULRO can be easilyand accurately maintained and updated, and can be used to link thegeographic items associated with locations in the file-of-reference withcorresponding location information 155, 156, 157, 158, 159 in one ormore third-party files 150, 152, 154. As shown in FIG. 1, a singlegeographic item associated with a location, for example location 120,may be linked to a single ULRO 110 that links to a single third-partyfile 150. Alternatively, a single geographic item associated with alocation, for example location 122 may be linked to a single ULRO 112that links to a plurality of third-party files 150, 152.

The use of ULRO hierarchies, and ULRO groups, both of which aredescribed in further detail below, allows other types of linking, sothat almost any combination of file-of-reference and third-party-file ispossible. Furthermore, links 160, 162, 164, 166, 170, 172, 174, 176, 180can be either uni-directional pointers, bi-directional pointers, or amix of both uni- and bi-directional pointers. This feature providesthat, while in FIG. 1, the file-of-reference 130 appears as a base map,it is also possible to treat any of the third-party files equally as thefile-of-reference, and for the locations therein to be similarly linkedto information in the other files. The bi-directional nature of the ULROmapping allows any third-party file to act as the file-of-reference, andallows the file-of-reference to act as a third-party file, depending onthe particular application.

FIG. 2 is an illustration that depicts an environment including a ULROcorresponding to a selected geographic item associated with a locationin a file-of-reference, in accordance with an embodiment of theinvention. As shown in FIG. 2 the ULRO 210 allows for mapping oflocation-related information between an electronic file-of-reference230, and one or a plurality of third party files 274, each of whichfiles comprising one or more geographic items associated with a location220, together with associated pointers and information linking thefiles. As described above, the only mandatory field in the ULRO is theULRC 208. It is also mandatory that the set of name information and theset of coordinates not both be blank, although either one of thesefields can be blank for a particular ULRO.

As shown in FIG. 2, in accordance with an embodiment, the ULRO logicallyresides in three places within the ULRO environment. The bulk of theULRO can reside almost anywhere, such as within a file on a serverconnected to the Internet. The complete ULRO also includes othercomponents, (i.e. back-pointers), that are physically associated withthe file-of-reference 230, and with the third-party files 274respectively. In accordance with an embodiment, the ULRO 210 comprises aset of name information 206, a coordinate super-set 207, a ULRC 208, afile-of-reference pointer field 209, a third-party file pointer field211, a file-of-reference back-pointer field 212; a third-party fileback-pointer field 205; and a metadata field 216.

In accordance with an embodiment, the set of name information 206comprises one or more of the following: 1) an address 217, which in turncomprises one or more of the following: 1a) a postal code 218, 1b) astreet number 219, 1c) a street name 221; 1d) a hierarchical areaaddress system with a sequence of names 222; and 1e) other addressinformation 223; 2) a named place 224; 3) a telephone number 228; 4)geographic name information 231; and 5) other name information 234. Inaccordance with an embodiment, the geographic name information 231comprises one or more of the following: 4a) name information for a pointfeature 236; 4b) name information for a line feature 238; 4c) nameinformation for an area feature 240; 4d) name information for a volumefeature 242; 4e) name information for a segment of a line feature 244;4f) name information for a sector of an area feature 246; 4g) nameinformation for a section of a volume feature 248; and 4h) nameinformation for a plurality of related geographic items 250.

In accordance with an embodiment, the ULRO comprises one, or aplurality, k, of coordinate super-sets 207, wherein k is the number ofcoordinate super-sets comprised in the physical location that is in turnassociated with the geographic item 220. For clarity, in the exampleshown in FIG. 2, a single coordinate super-set 203 is illustrated, but aULRO could comprise one, two, or more coordinate super-sets. Eachcoordinate super-set 203 comprises k geographic coordinate sets 251. Thegeographic coordinate set 251 in turn comprises geographic coordinates,such as a latitude 252 and a longitude 254, and may also comprise anelevation 256. In accordance with an embodiment, the coordinatesuper-set 203 also comprises a coordinate classification 258 and othercoordinate information 260. Optionally, information relating to a linearreferencing system 259, such as those used in conjunction with majormotorways or cell phone towers, can be included. This may, for example,include information relating to a cellular phone network associated withthe location 220. This allows the system to use cell phone towers orlinear referencing schemes or a combination of any of these instead ofgeographic coordinates, or alternatively the system can use acombination of both geographic and cell phone coordinates. In otherembodiments, the coordinate super-set can be assigned with reference toa transportation network such as a railway system or a highway linearreferencing system.

As described above, the ULRC 208 uniquely corresponds to the location.In accordance with an embodiment, the ULRC 208 comprises anidentification code 262. The ULRC 208 may also comprise other ULRCinformation 264.

In accordance with an embodiment, the file-of-reference pointer field209 comprises, when appropriate, a file-of-reference pointer 213 thatdesignates said location 220 in said file-of-reference 230. Eachfile-of-reference pointer 213 may further comprise one or more of thefollowing: a time of creation 266 of the file-of-reference pointer;information 268 identifying a type and class 269 of thefile-of-reference pointer field, and other file-of-reference pointerfield information 270.

In accordance with an embodiment, the third-party file pointer field 211comprises one or more third-party file pointers 272, each of whichuniquely designates one or more said location-associated item(s) 220 inone of said one or more third-party files 274. The number of third-partyfile pointers 272 pertaining to a particular one geographic itemassociated with a location 220 equals the total number of associationswithin those third-party files 274 that comprises the geographic itemassociated with the location 220. For any particular third-party file,there may be either one, or more than one association within each file.Assuming that each third-party file will usually provide at least someinformation for the geographic item associated with the location, thenthe total number of third-party pointers will typically be at leastequal to the number of third-party files, but will often be greater bythe number of additional associations. Each third-party file pointer 272may further comprise one or more of the following: a time of creation276 of the third-party file pointer, a type 278, and class 279 of thethird-party file pointer, and other third-party file pointer fieldinformation 280.

In accordance with an embodiment, the file-of-reference back-pointerfield 212 comprises a file-of-reference back-pointer 214 pointing fromthe file-of-reference 230 back to said central component of said ULRO210, and more specifically back to the ULRC code, 262. Thefile-of-reference back-pointer, while a part of the logical ULRO, isresident in the file-of-reference and is there to facilitate the two waytraversal between data items. Each file-of-reference back-pointer 214may further comprise one or more of the following: a time of creation291 of the file-of-reference back-pointer; a type 292 and class 293 ofthe file-of-reference back-pointer; and other file-of-referenceback-pointer information 294.

In accordance with an embodiment, the third-party file back-pointerfield 205 comprises one or more third-party file back-pointers 218,wherein each third-party file back-pointer 218 uniquely points from oneof the third-party files 274 back to the ULRO 210, and more specificallyback to the ULRC code 262. The third-party file back pointer, while apart of the logical ULRO, is resident in the third-party file, and isthere to facilitate the two-way traversal between data items. As withthe number of third-party file pointers above, the total number ofthird-party file back-pointers 218 associated with a particular location220 will typically be at least equal to the number of third-party files274 comprising the location, but since some third-party files mayprovide two or more associations, the total number will often be greaterby that number of additional associations. Each third-party fileback-pointer 218 may further comprise one or more of the following: atime of creation 295 of the third-party file back-pointer, informationidentifying a type 296, and class 297 of the third-party fileback-pointer, and other third-party file back-pointer information 298.

The embodiment shown in FIG. 2 also includes a metadata field 216comprising one or more of the following: a ULRO classification 282, atime of creation 284 of the ULRO, a type 285 and class 286 of the ULRO,and other metadata information 287. In accordance with an embodiment,the metadata information can be used to create hierarchical linksbetween the ULROs, as described in further detail below. In accordancewith other embodiments, the hierarchical information can be maintainedin other logical components. With the star configuration shown in FIG.2, it is easier to add another third party or user file (i.e. the totalnumber N then growing to N+1) without affecting all of the previoususers or third parties. For example, to establish a link or “connection”between an object in a first map and an object in a second map (assumingthey are different versions of the same object), the system mustmaintain a pointer from the first map to the second map (and also fromthe second map to the first map). If a third map is subsequentlyintroduced, together with its objects, then the first and second mapsmust both point to the new object in this third map, and similarly thethird map must point back to both the first and second maps. So over theoriginal two links are now introduced four new ones. Using a traditionalmethod the number of such links would be N! (N factorial). However, inaccordance with an embodiment of the present invention, the ULROprovides that each of the first, second, and third maps only need topoint to the ULRO of the object under consideration; while the URLOpoints to the objects of the first, second, and third maps. Thus, usingthis approach only 2 times N pointers are needed. It will be evidentthat, for a value of N equal to 3, then the total number of links willbe identical using either approach, but for a value of N larger than 3,then the star configuration is “cheaper” (i.e. it requires fewer links).The larger the value of N, the greater the efficiencies.

FIG. 3 is a flow chart that illustrates the flow of a ULRO process inaccordance with an embodiment of the invention. As shown therein, thesystem or process receives a request for a ULRO, together with some ofthe information defining the location within it; and subsequentlycreates a ULRO. As described above, in accordance with an embodiment theULRO comprises any of eight components: a set of name information; asuper-set of coordinates; a ULRC; a file-of-reference pointer; athird-party file pointer field; a file-of-reference back pointer; athird party back pointer; and a metadata field.

As described above, the only mandatory field in the ULRO is the ULRC. Itis also mandatory that the set of name information and the set ofcoordinates not both be blank, although either one or the other of thesefields can be blank for a particular ULRO. In step 300, a set of nameinformation corresponding to a selected location s determined, whereinthe location is also contained in one or more third-party files. In step310, a super-set of coordinates corresponding to the location isdetermined. Subsequently, in step 320 the system provides the assignmentof a ULRC to the location, if a ULRO does not already exist for theselected location. This ULRC is permanent and unique in its reference tothis location. If a ULRO does already exist, then in step 320, the fullULRO is retrieved from a central repository. In step 330 afile-of-reference pointer field is created, comprising afile-of-reference pointer that designates a geographic item associatedwith a location in the file-of-reference. In step 340, a third-partyfile pointer field is created comprising one or more third-party filepointers, each of which uniquely designates the one or morelocation-associated geographic items in one of the one or morethird-party files. In step 350, a file-of-reference back-pointer fieldis created comprising a file-of-reference back-pointer pointing from thefile-of-reference back to the ULRC for that ULRO. This back-pointerphysically resides in the file-of-reference or in a side file connectedwith the file-of-reference. In step 360, a third-party file back-pointerfield is created comprising one or more third-party file back-pointers,wherein each third-party file back-pointer uniquely points from one ofthe location-associated items of one of the third-party files back tothe ULRC for that ULRO. This back-pointer physically resides in thethird-party file or a side file connected with the third-party file. Instep 370, a metadata field is created. Finally, in step 380, the nameinformation, super-set of coordinates, ULRC, file-of-reference pointerfield, third-party file pointer field, file-of-reference back-pointerfield, third-party file back-pointer field, and the metadata field arelogically combined so as to create the ULRO. In the embodiment describedin FIG. 3, multiple instances of ULROs can have their central partsstored in files easily accessible to both third-party file suppliers andto virtual database (VDB) applications providers, in addition to theircustomers.

As described above, the only mandatory field in the ULRO is the ULRCcomponent. Similarly, not all of the above-described steps need beexecuted in forming the ULRO; nor do the executed steps need beperformed in a particular sequence, or even at the same chronologicalmoment in time. For example, some information, such as a nameinformation, may be available at a first point in time, and may beincluded in the ULRO then. Other information, such as a coordinateinformation, may only become available at a later point in time, perhapsdays or months later, and may be included in the ULRO only if and whenthat information becomes available.

FIG. 4 is a flow chart that illustrates in more detail the flow of aprocess in accordance with an embodiment of the invention. Each of thesteps shown in FIG. 4 corresponds largely to one or more of the logicalentities shown in FIG. 2. As shown therein, the system (or process)receives information about a geographic item associated with a location,and creates a ULRO comprising any of the following components: a set ofname information; a super-set of coordinates; a ULRC; afile-of-reference pointer field; a third-party file pointer field; and ametadata field; together with any applicable file-of-referenceback-pointer field and third-party file back-pointer field.

The process shown in FIG. 4 comprises a number of steps or actions,which can generally be performed in any order. In particular, several ofthe steps are properly considered optional actions by the system, whichmay or may not be actually performed, such as for example, the decisionto include a street number in an address, or not. As described above,the executed steps may also be performed at different chronologicalmoments in time. The various options are shown in FIG. 4 for purposes ofcompleteness. Depending on the actual implementation some of these stepsmay be entirely omitted, except that, in accordance with one embodimentthe only mandatory field is the ULRC. It is also mandatory that the setof name information and the set of coordinates not both be blank,although either one of these variables can be blank for a particularULRO.

In step 400, the system determines a set of name informationcorresponding to a geographic item that is associated with a location,wherein the location also has location-associated geographic itemscontained in a file-of-reference, or in one or more third-party files.In step 404, the system determines a set of name information thatcomprises one or more of the following: an address 406; a named place408; a telephone number 412; geographic name information 414; and othername information 416. As part of the address information, in step 418,the system determines an address that comprises one or more of thefollowing: a postal code 420; a street number 422; a street name 423; ahierarchical area address system with a sequence of names 424 and otheraddress information 425. As part of the geographic name information, instep 426, the system determines a geographic name information thatcomprises one or more of the following: name information for a pointfeature 428; name information for a line feature 430; name informationfor an area feature 432; name information for a volume feature 434; nameinformation for a segment of a line feature 436; name information for asector of an area feature 438; name information for a section of avolume feature 440; and name information for one or more relatedlocations 442. The set of name information for these one or more relatedlocations is in addition to the name information for the primarylocation, and may include: information on the relationship among thetypes of geographic name information; and other name information. Forexample, if the ULRO defines geographic item associated with the city ofname “San Francisco”, then the name information for a related locationmight be “California”, and the relationship may be of the type “citywithin a state”.

In step 450, the system determines a super-set of coordinatescorresponding to the geographic item associated with the location.

In step 452, the coordinate super-set comprises a number, k, ofcoordinate sets needed to describe the geometry of the location. Eachcoordinate set may comprise one or more of: a coordinate classification455, geographic coordinate set 456, information 457 relating to a linearreferencing system, such as those used in conjunction with majormotorways or cell phone towers, and other coordinate information 458. Aspart of the geographic coordinate set, in step 459, each geographiccoordinate set may comprise: a latitude 460, and a longitude 461, or theequivalent information from a different coordinate reference system.Each geographic coordinate set may in addition comprise an elevation462.

In step 464, the system assigns a ULRC to the geographic item associatedwith the location if a ULRO does not already exist for the selecteditem. If a ULRO does already exist, then the ULRO is retrieved from acentral repository. In step 466, the ULRC that is created or retrievedcomprises an identification code. In step 468, the ULRC may compriseother ULRC information.

In step 469, when appropriate, a file-of-reference pointer field iscreated; comprising a file-of-reference pointer that designates saidgeographic item associated with the location in the file-of-reference.In step 470, the file-of-reference pointer field may comprise one ormore of the following: a time of creation of the file-of-referencepointer field 471, a type and class of the file-of-reference pointerfield 473 and other file-of-reference pointer field information 474. Inaccordance with an embodiment, the system can utilize a technique ofoffset pointer addressing described in copending European patentapplication entitled “______”; Inventor Hans Ulrich Otto; filed ______,and incorporated herein by reference.

In step 475, a third-party file pointer field is created. Thethird-party file pointer field comprises one or more third-party filepointers, each of which uniquely designates the one or more geographicitems in the one of the one or more third-party files that comprised thelocation associated geographic item. In step 476, the third-party filepointer field may comprise one or more of: a time of creation of thethird-party file pointer field 477, a type 478 and class 479 of thethird-party file pointer field, and other third-party file pointer fieldinformation 480.

In step 481, when appropriate, a file-of-reference back-pointer field iscreated. The file-of-reference back-pointer field comprises afile-of-reference back-pointer pointing from the file-of-reference backto the ULRO, and specifically to the ULRC. In step 482, thefile-of-reference back-pointer field may comprise one or more of: a timeof creation of the file-of-reference back-pointer field 483; a type 484and class 485 of the file-of-reference back-pointer field; and otherfile-of-reference back-pointer field information 486. The ULRO can becontinuously updated and fields can be filled in at any time.

In step 487, a third-party file back-pointer field is created. Thethird-party file back-pointer field comprises one or more third-partyfile back-pointers, wherein each third-party file back-pointer uniquelypoints from one of said location-associated geographic items of one ofsaid third-party files back to the ULRO. The third-party fileback-pointer field may comprise one or more of the following: a time ofcreation of the third-party file back-pointer field 489, a type 490 andclass 491 of the third-party file back-pointer field, and otherthird-party file back-pointer field information 492. The third-partyfile back-pointer is not necessarily created at the same time as theULRO; it is often created when a ULRO receives a request from athird-party file that includes a geographic item to be associated withthe ULRO.

In step 493, a metadata field may be created. In step 494, the metadatafield comprises one or more of the following: a ULRO classification 495,a time of creation of the ULRO 496, a type and/or class of the ULRO 497,and other metadata information 498.

Finally, in step 499, the set of name information, the super-set ofcoordinates, the ULRC, the file-of-reference pointer field, thethird-party file pointer field, the file-of-reference back-pointerfield, the third-party file back-pointer field, and the metadata field,are combined to create the ULRO.

ULRO Advanced Features

As mentioned briefly above, several advanced features such as the use ofULRO hierarchies, and ULRO groups add extra functionality to the ULROsystem described herein, and allow for great flexibility in linkinggeographic location information across increasing numbers of third-partyfiles and resources:

ULRO Relationships and Hierarchies—FIG. 5 is an illustration thatdepicts the use of ULRO relationships and hierarchies, in accordancewith an embodiment of the invention. FIG. 5 shows a system similar toFIG. 1, in which ULROs comprising permanent identification codes areassigned to geographic items associated with a location 122, 124, 126 inan electronic file-of-reference 130. The ULROs link the geographic itemsassociated with locations in the file-of-reference with correspondinggeographic information associated with a location in one or morethird-party files 150, 152, 154. As shown in FIG. 5, a single geographicitem associated with a location 120, may be linked to a single ULRO 112.Using ULRO relationships, this ULRO 112, may in turn be linked to otherULROs 114, 116 via ULRO relationships 502, 504. (Other ULROrelationships 506 may exist to link ULROs 114, 116 to one another).Since, for example, ULRO 114 and ULRO 116 do not themselves have adirect pointer link to the geographic item 122, without such ahierarchical link the system would only link the geographic informationassociated with location 122 via ULRO 112 to location-relatedinformation 156, 158. However, using ULRO relationships, the system isable to also link ULROs 114, 116, together with their location-relatedinformation 157, 159 to geographic information associated with location122.

A special form of ULRO relationship is a ULRO hierarchy. In accordancewith an embodiment, a ULRO hierarchy specifies that a first ULRO is aparent of a second ULRO; while the second ULRO is a child of the firstULRO. A parent ULRO may have many children, and grandchildren ULROs.Using ULRO hierarchies, the system can provide relationships that equateto familiar and easily understood concepts. For example, if ULRO 116represents the city of San Francisco, then its parent ULRO 114 may bethe state of California, and its parent the entire United States 112.When the ULRO relationship is a hierarchy, then to both avoid circularrelationships, and to reduce the number of links that must be changed toreflect updated information, usually only parent/child links aremaintained. So, as shown in FIG. 5, only the parent/child links 504, 506would be used. The “grandparent” link 502 would not be used, nor wouldit be desirable to have it present in the system.

In accordance with an embodiment, the metadata information component canbe used to record and maintain the relationships and hierarchical linksbetween the ULROs. In accordance with other embodiments, the ULROrelationship and hierarchical information can be maintained in otherlogical components.

ULRO Groups—FIG. 6 is an illustration that depicts the use of ULROgroups, in accordance with an embodiment of the invention. FIG. 6 alsoshows a system similar to FIG. 1, in which ULROs comprising permanentidentification codes are assigned to geographic items associated withlocations 122, 124, 126 in an electronic file-of-reference 130, whereinULROs link the geographic items associated with locations in thefile-of-reference with corresponding location information in one or morethird-party files 150, 152, 154. As shown in FIG. 6, in addition to thenormal case in which a single geographic item associated with a location122, 124, 126 is linked to a single ULRO 112, here another geographicitem 512 can be linked using a group link 514 to a group of the ULROs112, 114, 116, the group itself being indicated by the box 510. Linkinga single location to a group in this manner allows for more optimalconfiguration, and also equates to familiar and easily understoodconcepts. For example, if items 122, 124, and 126 are local informationpertaining to different counties in the state of California, then group510 may be the entire group of ULROs for the counties in the state.Selecting item 510 is equivalent to selecting each of items 122, 124 and126, but may be more convenient in certain applications

Offset Pointer Addressing—In accordance with an embodiment, offsetpointer addressing allows the system to provide information forlocations for which no current object exists. In this instance, insteadof specifying a pointer to the geographic item in the file-of-referenceor third party file, the system can specify a pointer to anothergeographic item in the file, together with an appropriate offset. At alater time, direct or non-offset pointers may or may not be subsequentlycreated for that location. In accordance with an embodiment, the offsetpointer can be included in the forward pointer to file of reference, box213, shown in FIG. 2 and described above.

In accordance with an embodiment, the system can utilize a technique ofoffset pointer addressing described in copending European patentapplication entitled “______”; Inventor Hans Ulrich Otto; filed ______,and incorporated herein by reference.

Missing Pointers—In accordance with an embodiment, the ULRO techniqueallows the system to include support for “missing pointers”. When adesired geographic item associated with a location is not present in thefile-of-reference, but one or more of the third-party files do haveassociated information for that geographic item associated with alocation, then only those pointers between the third-party file and theULRO may be created. The pointers that would normally link the ULRO tothe file-of-reference are missing. Since, as described above, the stepsused to form a ULRO can be executed in any sequence, or even atdifferent chronological moments in time; similarly the pointers betweenthe various file-of-reference and third-party-files can also be createdat different chronological moments in time. When the information becomesavailable, the “missing pointer” is properly formed, linking the newinformation to the ULRO.

System Implementation

FIG. 7 is a diagram that schematically illustrates an example of asystem that can be used with an embodiment of the invention. As shown inFIG. 7, the system 520 allows for a ULRO to be created based ongeographic item that is associated with a location 540 contained in anelectronic file-of-reference 550, and that also has one or morelocation-associated geographic items contained in one or a pluralitythird-party files 594, 595. Although this figure depicts components aslogically separate, such depiction is merely for illustrative purposes.It will be apparent to those skilled in the art that the componentsportrayed in this figure can be combined into a single component, or canbe divided into further separate software, firmware and/or hardwarecomponents. Furthermore, it will also be apparent to those skilled inthe art that such components, regardless of how they are combined ordivided, can execute on the same computing device or can be distributedamong different computing devices connected by one or more networks orother suitable communication means.

As shown in FIG. 7, the system 520 typically includes a computing device524 which may comprise one or more memories 528, one or more processors530, and one or more storages or repositories 532 of some sort. Thesystem 520 may further include a display device 534, including agraphical user interface or GUI 536 operating thereon by which thesystem can display digital maps and other information. The device mayunder some other circumstances be text-based.

The system shown herein can be used to display the contents of theelectronic document to an operator 538, or automatically to a computerprocess running on processor 530. Because the software for assigningULROs will typically be proprietary, hard coding 544 can be used orembedded within the logic of the system to generate ULROs. When all orpart of an electronic file-of-reference 550 is retrieved from externalstorage 553, (which in some instances may be the same storage as storage532), ULROs and/or ULRCs will be created if they were not previouslycreated (or alternatively will be fetched from a central repository 547if they had been previously created) to correspond to a geographic itemthat is associated with a location 540 comprised in the electronicfile-of-reference 550. The newly created, or retrieved ULRO is used tolink the geographic item in the file-of-reference withlocation-associated information in the third-party files. In some casesside files comprising third-party pointers may also be used. Asdescribed above, a feature of the system 520 is its ability tofacilitate links with locations and location associated geographic itemsin a wide variety of present and future document formats. Those ULROscan be created by various schemas. One such schema is to generate a ULROwhenever a need arises (such as request by a third-party based on itsdata needs). Another schema of generating ULROs is to preemptivelycreate ULROs based on all addresses and location objects in thefile-of-reference. Hybrid and other schema regimes are possible andconceivable.

Although shown as a single system in FIG. 7, several of the componentscan be distributed over a variety of different computer systems andprocessors. For example, in accordance with one embodiment, the user'scomputer can communicate 572, 574 with a remote server 570 on which allof the database, file-of-reference, third-party-files, and othercomponents are located. However, in other embodiments, for example, thefile-of-reference may be located on a different machine from thethird-party files, while the ULRO repository exists on yet anothermachine. Indeed, it is a feature of the present system that the ULROallows for information to be dynamically linked from a variety ofdifferent sources, including different vendors, even if those sourcesare widely distributed over a large area, or a large area network, suchas the Internet.

Embodiments of the present invention may be conveniently implementedusing a conventional general purpose or a specialized digital computeror microprocessor programmed according to the teachings of the presentdisclosure, as will be apparent to those skilled in the computer art.Appropriate software coding can readily be prepared by skilledprogrammers based on the teachings of the present disclosure, as will beapparent to those skilled in the software art. Embodiments of theinvention may also be implemented by the preparation of applicationspecific integrated circuits or by interconnecting an appropriatenetwork of conventional component circuits, as will be readily apparentto those skilled in the art.

Embodiments of the present invention include a computer program productwhich is a storage medium (media) having instructions stored thereon/inwhich can be used to program a computer to perform any of the processesof embodiments of the present invention. The storage medium can include,but is not limited to, any type of disk including floppy disks, opticaldiscs, DVD, CD-ROMs, microdrive, and magneto-optical disks, ROMs, RAMs,EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or opticalcards, nanosystems (including molecular memory ICs), or any type ofmedia or device suitable for storing instructions and/or data.

Stored on any one of the computer readable medium (media), embodimentsof the present invention include software for controlling both thehardware of the general purpose/specialized computer or microprocessor,and for enabling the computer or microprocessor to interact with a humanuser or other mechanism utilizing the results of embodiments of thepresent invention. Such software may include, but is not limited to,device drivers, operating systems, and user applications. Ultimately,such computer readable media further includes software for performingembodiments of the present invention, as described above.

Included in the programming (software) of the general/specializedcomputer or microprocessor are software modules for implementing theteachings of the present invention, including, but not limited to,creating a universal location referencing object (ULRO) corresponding toa selected location in an electronic file-of-reference, one or morelocation-associated geographic items also being comprised in one or morethird-party files; determining a set of name information correspondingto a selected location; determining a super-set of coordinatescorresponding to the location; assigning a universal locationreferencing code (ULRC) uniquely corresponding to the location; creatinga file-of-reference pointer field comprising a file-of-reference pointerthat designates the location in the file-of-reference; creating athird-party file pointer field comprising one or more third-party filepointers, wherein each third-party file pointer uniquely designates theone or more location-associated geographic item(s) in one of the one ofmore third-party files; creating a file-of-reference back-pointer fieldcomprising a file-of-reference back-pointer pointing from saidfile-of-reference back to said ULRO resident in the file-of-reference oran associated side file; creating a third-party file back-pointer fieldcomprising third-party file back-pointers resident in said third partyfile or an associated side file, wherein each said third-party file backpointer uniquely points from one location-associated geographic item ofsaid third-party files back to said ULRO; creating a metadata fieldconfigured to comprise metadata relating to the ULRO; and combining theset of name information, the super-set of coordinates, the ULRC, thefile-of-reference pointer field, the third-party file pointer field, thefile-of-reference back-pointer field, the third-party file back-pointerfield, and the metadata field so as to create the ULRO.

The foregoing description of the present invention has been provided forthe purposes of illustration and description. It is not intended to beexhaustive or to limit embodiments of the invention to the precise formsdisclosed. Many modifications and variations will be apparent to thepractitioner skilled in the art. The embodiments were chosen anddescribed in order to best explain the principles of the invention andits practical application, thereby enabling others skilled in the art tounderstand the invention for various embodiments and with variousmodifications that are suited to the particular use contemplated. It isintended that the scope of the invention be defined by the followingclaims and their equivalents.

1. A system that uses universal location referencing objects to provide geographic item information for a location, comprising: an interface to a file-of-reference, wherein geographic item information, including a geographic item associated with a location; an interface to a third-party file that comprises additional geographic item information that may be associated with the location; a universal location reference object that includes (a) a universal location reference code that uniquely identifies the location, (b) identifying information for the location, and (c) links to the additional geographic item information in the third-party file; a logic that, in response to a request for information for a particular location, retrieves a universal location reference object for the particular location, traverses the links, associates the additional geographic item information in the third-party file with the geographic item information in the file-of-reference, and provides the resultant information as a response to the request.
 2. The system of claim 1, wherein the location is a physical location in the real world, and wherein the geographic item information is a feature information that is associated with the physical location.
 3. The system of claim 2, wherein the physical location has a unique universal location reference code that uniquely identifies that physical location in the real world.
 4. The system of claim 1, wherein some of the links to the additional geographic item information in the third-party file are defined in a side file that is referenced by the universal location reference object.
 5. The system of claim 1, wherein the system comprises interfaces to multiple third-party files that comprise additional geographic item information that may be associated with the location, and wherein the universal location reference object includes links to the additional geographic item information in the multiple third-party files.
 6. The system of claim 1, wherein the location is represented as a location in an electronic map, and wherein the geographic item information is used to display features on the map for the location.
 7. A method for providing geographic item information for a location, using universal location referencing objects, comprising the steps of: accessing a file-of-reference that comprises geographic item information, including a geographic item associated with a location; accessing a third-party file that comprises additional geographic item information that may be associated with the location; and in response to a request for information for a particular location, retrieving a universal location reference object for the particular location, wherein the universal location reference object includes (a) a universal location reference code that uniquely identifies the location, (b) identifying information for the location, and (c) links to the additional geographic item information in the third-party file; traversing the links, and associating the additional geographic item information in the third-party file with the geographic item information in the file-of-reference, and providing the resultant information as a response to the request.
 8. The method of claim 7, wherein the location is a physical location in the real world, and wherein the geographic item information is a feature information that is associated with the physical location.
 9. The method of claim 8, wherein the physical location has a unique universal location reference code that uniquely identifies that physical location in the real world.
 10. The method of claim 7, wherein some of the links to the additional geographic item information in the third-party file are defined in a side file that is referenced by the universal location reference object.
 11. The method of claim 7, wherein the method further comprise accessing multiple third-party files that comprise additional geographic item information that may be associated with the location, and wherein the universal location reference object includes links to the additional geographic item information in the multiple third-party files.
 12. The method of claim 7, wherein the location is represented as a location in an electronic map, and wherein the geographic item information is used to display features on the map for the location.
 13. The method of claim 7, wherein the request is received from a user in order to generate the map and any associated features for the location.
 14. The method of claim 7, wherein the request is received from a system or another process in order to retrieve location related information.
 15. The method of claim 7, wherein if a universal location reference object does not already exist for the location or the geographic item associated with the location, then the method further comprises creating a universal location reference object.
 16. The method of claim 7, wherein the method includes retrieving a plurality of universal location reference objects, and wherein at least some of the plurality of universal location reference objects are linked by universal location reference object links to create a relationship between the universal location reference objects.
 17. The method of claim 16, wherein the universal location reference object links are hierarchical links that create a hierarchical relationship between the universal location reference objects.
 18. The method of claim 7, wherein the method includes retrieving a plurality of universal location reference objects, and wherein the geographic item associated with a location is in turn linked to a group of universal location reference objects selected from the plurality of universal location reference objects.
 19. The method of claim 7, wherein the (b) identifying information for the location included in the universal location reference object comprises any of name, coordinate, or link information for the location.
 20. The method of claim 19, wherein name, coordinate, or link information for the location can be added, updated or deleted in the universal location reference object at any time. 